The invention relates generally to systems and methods adapted to, or benefiting from the incorporation of data related to physical effects. Certain embodiments of the invention are related to systems adapted to run a physics simulation with the aid of a physics co-processor, or a so-called Physics Processing Unit (PPU). Several exemplary embodiments of a PPU-enabled system are disclosed in relation to U.S. patent application Ser. No. 10/715,370 filed Nov. 19, 2003; Ser. No. 10/839,155 filed May 6, 2006, Ser. Nos. 10/982,764 and 10/982,791 both filed Nov. 8, 2004; and, Ser. No. 10/988,588 filed Nov. 16, 2004. The subject matter of these commonly assigned, pending patent applications is hereby incorporated by reference.
The term “PPU-enabled” generally describes any system incorporating a PPU to generate physics data for consumption by a main application running on a Central Processing Unit (CPU), such as Pentium® or similar microprocessor. The PPU and CPU may take many forms, but are generally implemented as separate computational hardware platforms capable of at least some level of mutually independent, asynchronous computational operation. Mutual independent operation certainly allows for designation of a master/slave relationship between PPU and CPU, so long as some level of independent operation is possible.
The term “physics data” encompasses any data and/or data structure related to a mathematical algorithm or logical/mathematical expression adapted to solve a physics problem or express a physics-based relationship. In the context of a PC or game system, such problems and/or relationships are “virtual” in nature. That is, they exist only in animated scenes produced by a main application. This virtual existence notwithstanding, the constituent physics problems and physics-based relationships characterizing physics data are defined, at least in part, by generally recognized physics principles.
Any set of logical computations and/or algorithms operating upon physics data is termed a “physics simulation.” Within the context of a PPU-enabled system, a physics simulation generally runs on the PPU in cooperation with the CPU to generate a body of physics data that accurately defines the movement and/or interaction of objects and features in an animated scene as displayed by a peripheral device associated with the system. For purposes of the description that follows, individual components within the constellation of possible objects and features capable of being displayed as part of a physics simulation will be generally terms “actors.”
Such computationally derived, physics-enhanced animations form an increasingly important aspect of numerous applications. Computer games are an excellent example of applications that benefit from the added realism provided by animations derived from a defined set of physics-based parameters and data. The term “animation” is used here to generally describe any visual representation of an event or scene. The term “physics-based animation” refers to any animation derived, at least in part, from a physics simulation or least one computational process operating on physics data defining a physical characteristic or behavior of an actor in the scene. In this context, the physics simulation is often said to be driving the resulting animation. However, the direct relationship between the physics simulation and the resulting animation, and the fact that the underlying physics simulation is not apparent to the system user typically results in an alternative use of the terms “animation” and “simulation.”
Conventional systems, such as Personal Computers (PCs) or Game Consoles, run various main applications, such as games, that are visually and tactilely enhanced by the incorporation of physical effects. A specialty software program resident in the system and generally referred to as a “physics engine” provides the programming tools and functional capabilities necessary to simulate various kinds of physical effects. A conventional, software-based physics engine provides a programmer with increased latitude to assign virtual mass, coefficients of friction, etc., to actors animated within a scene produced by execution of the main application. Similarly, virtual forces, impulses, and torques may be applied to the actors. In effect, the conventional physics engine provides programmers with a library of procedures to simplify the visual creation of scenes having physical effects (i.e., physics-based interactions between actors in the scene).
The physics engine typically provides, or is associated with, an Application Programming Interface (API) through which the main application may communicate with the physics engine. The physics engine API may be specially provided or it may be part of a larger, general API associated with the system or an operating system (OS) running on the system. Using the physics engine API and conventionally understood techniques, the main application creates one or more animated scenes. Scenes or scene combinations are sometimes referred to as “worlds.”
In concert with the physics engine, the main application typically populates a given scene with one or more actors. Specific actors may take many forms, including; an object, an object feature or element, a visual effect, etc. Indeed, actors have been generically referred to as “objects,” but this term should not be construed as being limited in this context to the customary meaning typically ascribed to only inanimate things. In the description that follows, reference to an object is merely a convenient reference to one type of actor in an animated scene.
FIG. (FIG) 1A and FIG. 1B generally illustrate two possible relationships between physics engines and other selected system components. FIG. 1A illustrates a main application 1 communicating with a conventional, software-based physics engine 3 through an associated API 2. The term “API” is used throughput this description to denote any set of definitions or established relationships generally enabling one piece of software to communicate with another piece of software. APIs are subject to wide variations in expression and definition, but generally provide some level of abstraction usually (but not necessarily) between a lower-level and higher-level software.
FIG. 1B illustrates main application 1 communicating with a hardware-based PPU 5 through an associated API 2 and device driver 4. A device driver is a conventional piece of software enabling an application or other piece of software to interact with a hardware device, such as a PPU. Device drivers are often provided by an operating system like Windows or Linux, and may be viewed as a manual of sorts giving the operating system a set of instructions adapted to operate or interacting with the particular hardware device.
The examples illustrated in FIGS. 1A and 1B show two different implementations of a physics engine. In FIG. 1A, the physics engine is implemented wholly in software running on the system CPU. In FIG. 1B, the physics engine is largely implemented using a PPU externally provided and/or independently operating in relation to the CPU running the main application. Thus, the PPU of FIG. 1B may take the form of a PCI connected co-processor, a separate co-processor additionally provided within the system, or a separate processing core within a multi-core processor.
However implemented, the hardware and/or software components forming the physics engine cooperate to generate the physics data necessary to produce a temporal sequence of physics-enhanced animated scenes. For example, consider the scenes A and B produced by physics engine 6 of FIG. 2, each presumptively containing physical effects. Each scene comprises a multiplicity of actors (“a” through “h”), wherein the various actors are capable of interacting (e.g., affecting and/or being affected by) one with another. Actor interactions take place in the virtual physicality of the animated scene. However, conventional scenes A and B are completely independent of one another. That is, actors “a” through “e” in scene A cannot interact with actors “f” though “h” in scene B. Different scenes are like completely separate worlds—they do not influence or affect one another in any way.
As noted above, conventional software-based physics engines are implemented as libraries of sorts running on a system CPU (e.g., a main computational hardware platform in the system). Conventionally, the CPU must synchronously run the software implementing the main application with software implementing the physics engine. However, the use of multiple processors, multiple execution threads, and multiple processing core systems is becoming increasingly common. Further, the availability of PPU-enabled systems, whether the PPU is provided as a stand alone device, an add-on device, or subsystem (e.g., a PCI or PCI Express connected subsystem), an additional system processor, a designated processing core in a multi-core processor, or as a separate hardware thread, has dramatically altered the possible mechanisms and manner by which physics data may be generated and provided to a main application. That is, no matter its actual physical implementation, the PPU is well adapted to run physics simulations, because its additional processing power enables real-time simulation of larger, more complex scenes having a larger numbers of actors with more detailed geometry, texture, and features.
Unfortunately, hardware and/or software variations between different systems, each potentially running the same main application pose a significant problem to both application developers and system vendors. For example, a single commercial version of a main application would ideally be capable of running on different systems having a range of hardware and software capabilities. Differing hardware capabilities may include, for example, PPU-enhanced systems, systems comprising an up-to-date CPU or a multi-core processor, systems comprising a legacy processor or single core processor, and systems having various quantities and/or types of available memory. If on one hand, a main application is developed to incorporate a cutting-edge, complex physics simulation and therefore requires state-of-the art hardware and/or software, then only customers having high-end systems will be potential customers. If on the other hand, the main application is “dumbed-down” to be useable across a broader range of systems including older systems, then the application loses some of the potential benefits afforded by the inclusion of maximally-complex physics simulations.